Diagnostics for iOS status-bar tap scroll-to-top (#3589)#4868
Merged
shai-almog merged 6 commits intomasterfrom May 5, 2026
Merged
Diagnostics for iOS status-bar tap scroll-to-top (#3589)#4868shai-almog merged 6 commits intomasterfrom
shai-almog merged 6 commits intomasterfrom
Conversation
Adds a Simulate -> iOS Status Bar Tap menu item that mirrors the synthesized tap (displayWidth/2, 0) dispatched by scrollViewShouldScrollToTop: in CodenameOne_GLViewController.m. It reports the responder at that coordinate plus the relevant theme constants, so users can verify on the simulator whether the device tap path would land on the built-in StatusBar button or be blocked by another component. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Collaborator
Author
|
Compared 7 screenshots: 7 matched. |
Records each scrollViewShouldScrollToTop: dispatch from the
status-bar tap proxy and exposes the counters as
Display.getProperty("cn1.iosStatusBarTap.*") so on-device code can
distinguish "iOS never delivered the scroll-to-top message" from
"iOS delivered it but a CodenameOne component intercepted the tap".
Properties:
cn1.iosStatusBarTap.count number of taps received
cn1.iosStatusBarTap.lastEpochMillis ms-since-epoch of last tap
cn1.iosStatusBarTap.lastX x of last synthesized tap
cn1.iosStatusBarTap.lastY y of last synthesized tap
cn1.iosStatusBarTap.proxyInstalled is the proxy view attached
cn1.iosStatusBarTap.diagnostics all of the above as a string
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
shai-almog
changed the title
Contributor
✅ Continuous Quality ReportTest & Coverage
Static Analysis
Generated automatically by the PR CI workflow. |
Collaborator
Author
|
Compared 90 screenshots: 90 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
…3589) Adds StatusBarTapDiagnosticScreenshotTest plus a StatusBarTapDiagnosticNative interface (iOS / JavaSE / Android / JS / Win impls). Each frame in the 2x3 grid alternates "scrolled to bottom" / "tap fired -> scrolled to top", overlaid with a glass pane showing the rising tap counter. The native interface routes simulateStatusBarTap() through the same path as scrollViewShouldScrollToTop:; the body is now factored into cn1FireStatusBarTap in CodenameOne_GLViewController.m so the screenshot test exercises the real counter+pointer-dispatch on iOS without needing a UIKit status-bar event. Other platforms stub the call (or fall back to Form.pointerPressed in the JavaSE impl) and the visible scroll is applied explicitly each frame, so the screenshot is deterministic across platforms. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Collaborator
Author
|
✅ JavaScript-port screenshot tests passed. |
Collaborator
Author
|
Compared 90 screenshots: 90 matched. Native Android coverage
✅ Native Android screenshot tests passed. Native Android coverage
Benchmark ResultsDetailed Performance Metrics
|
iOS build was failing: cn1FireStatusBarTap calls pointerPressedC and pointerReleasedC which are defined further down in the file. Add forward declarations so the function compiles. Replace the 2x3 animation grid with a side-by-side before/after composite. Each half is a full-height frame with a glass-pane header showing the counter, scroll position, and native-interface availability. Reads at a glance and avoids the JS-port animation-grid decode failures. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The JS port chunk-truncates large screenshot streams. The runner-level skip list addition wasn't enough (the test still ran on this branch's CI), so apply the same pattern as AbstractStickyHeaderScreenshotTest and short-circuit inside runTest with a SKIPPED status log. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
iOS baseline shows native:yes (real cn1FireStatusBarTap counter), Android shows native:no (stub impl) — both confirm the counter rises 0->3 and the scroll position flips bottom->top across the before/after composite. Captured from PR 4868 CI artifacts (ios-ui-tests + emulator-screenshot). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds three complementary diagnostics for the iOS status-bar tap scroll-to-top path. The fix from #4857 is in but the reporter still sees no scroll on device, so rather than another sweep these tools let them tell us where the path breaks.
Simulator side:
Simulate -> iOS Status Bar Tapmenu itemSynthesizes the same
(displayWidth/2, 0)tap thatscrollViewShouldScrollToTop:dispatches inCodenameOne_GLViewController.m. Pops a dialog with:paintsTitleBarBool/statusBarScrollsUpBoolconstantsForm.getResponderAt(displayWidth/2, 0)so the user can see whether the iOS device path would land on the built-inStatusBarbutton or be blocked by another componentThen actually fires
pointerPressed/pointerReleasedso any wired-up scroll-to-top is observable.iOS device side:
Display.getProperty("cn1.iosStatusBarTap.*")scrollViewShouldScrollToTop:now records each dispatch in static counters surfaced via:cn1.iosStatusBarTap.count-- number of taps receivedcn1.iosStatusBarTap.lastEpochMillis-- ms-since-epoch of last tapcn1.iosStatusBarTap.lastX/lastY-- coords of last synthesized tapcn1.iosStatusBarTap.proxyInstalled-- whether the proxy view is attachedcn1.iosStatusBarTap.diagnostics-- all of the above as a single stringLets a user run their app on a device, tap the status bar, and inspect the property to distinguish "iOS never delivered the message" from "iOS delivered it but a CodenameOne component intercepted the tap".
Regression coverage:
StatusBarTapDiagnosticScreenshotTestinscripts/hellocodenameoneA 2x3 frame grid alternating "scrolled to bottom" and "tap fired -> scrolled to top", with a glass-pane overlay showing the rising tap counter. The tap is fired through a new
StatusBarTapDiagnosticNativeinterface which on iOS calls a factored-outcn1FireStatusBarTap()(the body ofscrollViewShouldScrollToTop:) so the real counter and pointer-dispatch path are exercised; other platforms stub the call. The visible scroll is applied explicitly each frame so the screenshot is deterministic across iOS / Android / JavaSE.Test plan
Simulate -> iOS Status Bar Tapon a default iOS-themed form, confirm the dialog reports theStatusBarUIID and the form scrolls to top.paintsTitleBarBool: true, confirm the warning fires.StatusBar.Display.getProperty(\"cn1.iosStatusBarTap.count\", \"0\")increments andcn1.iosStatusBarTap.proxyInstalledreturnstrue.StatusBarTapDiagnosticScreenshotTestproduces an identical 2x3 grid on iOS, Android, and JavaSE, with the counter rising and the scroll position alternating between bottom / top.🤖 Generated with Claude Code